Public key cryptography involves the generation of an asymmetric key pair, usually referred to as the public and private key. They are so called because the private key is kept secret by the party implementing the cryptography scheme in question, whilst the public key is distributed to one or more other parties (though it need not be “public” in the sense of being freely or indiscriminately available—distribution of the public key in many situations may still be carefully restricted).
As illustrated schematically in FIG. 1, a public and private key pair is typically generated based on a large random number being input to a key generation function 102. The public key K′ and private key K are thus mathematically related to one another by the generation function and the random number, but due to the nature of this function then it is not practically feasible to derive or deduce the private key K from the public key K′. One example of a key generation function is an RSA (Rivest, Shamir and Adleman) algorithm. Details of this and other suitable algorithms for use in a key generation function 102 will be familiar to a person skilled in the art.
Public key cryptography comes in two kinds. The first is public key encryption, whereby a sender encrypts a message using the public key and the recipient decrypts the message using the private key, thus keeping the information content of the message secret from anyone other than the holder of the private key. The second kind is authentication, whereby a supplier of certain information “signs” that information using a private key. Any holder of the public key can then verify that the information did indeed originate from the holder of the private key, and is therefore authentic. The characteristic feature of asymmetric or public key techniques is that the key used to encrypt or sign the information is not the same as the key used to decrypt or authenticate it. The following relates to the latter kind of public key cryptography, for authentication.
As illustrated schematically in FIG. 2, such techniques can be used by a secure boot procedure in order to verify the authenticity of other software to be run on a processor. FIG. 2 shows a processor 204 in the form of an integrated circuit (IC), or “chip”. The processor chip 204 comprises a central processing unit (CPU) 206 and a first non-volatile on-chip memory 208, and optionally a second non-volatile on-chip memory 210. Furthermore, the CPU 206 is operably coupled to a non-volatile off-chip memory 212.
The first on-chip memory 208 is the primary boot memory, storing the primary boot code. The CPU 206 is hard-wired so as, upon start-up or reset of the processor, to automatically begin executing the primary boot code from the primary boot memory 208. When executed, the primary boot code performs the basic initialisation of the processor required to get it up and running. The primary boot memory 208 preferably takes the form of a secure Read Only Memory (ROM) which is arranged to be unalterable by customers or users, e.g. a one-time programmable memory in which the data elements are permanently fused once programmed such that the memory cannot be re-written.
The off-chip memory 212 may be used to store secondary boot code. The primary boot code includes a procedure whereby, once it has suitably configured the processor, it automatically instigates execution of the secondary boot code to provide further “soft” boot functionality. The secondary boot code allows some of the boot functionality of the processor 204 to be programmed “in the field” by the customer (e.g. a maker of a user terminal such as a wireless mobile cellular device in which the chip is to be incorporated), whereas the primary boot code comes pre-programmed from the manufacturer of the chip itself, and should not be alterable by the customer or user. The off-chip memory 212 could also be used to store applications for running on the processor, and/or data files. The off-chip memory 212 could for example be an erasable programmable memory (EPROM) such as an external flash memory.
Alternatively or additionally, the secondary on-chip memory 210 could be used to store secondary boot code, other applications, and/or data files. The secondary on-chip memory 210 could for example be an EEPROM such as an on-chip flash memory. Further, applications and data could be retrieved from a magnetic storage medium or even from a network such as the Internet.
A production processor is an instance of the processor supplied to a customer for use in a product such as a user terminal. Production processors are often configured to only authenticate software signed using production keys, locking the device to only run code that has been formally signed using these secure production keys. Particularly, the boot code is configured to verify that other code has been authentically signed before allowing it to be executed. For example, the secondary boot code may be configured to verify that applications have been authentically signed before allowing them to be loaded and executed.
As shown in FIG. 2, the signing process comprises inputting both a private key and the application code into a cryptography function 202, which outputs the code with a cryptographic signature based on the private key. The cryptography function 202 is a one-way function such as a hash function, details of which will be familiar to a person skilled in the art. It is this signed version of the application that is installed on the off-chip memory 212 (or secondary on-ship memory 210). The boot code comprises or has knowledge of the corresponding public key, and is configured to use the public key to verify the authenticity of this signature before allowing the application to be loaded and run on the processor (and to only to do so on condition of the verification). Thus the processor can verify that it is executing software that has been authorised for use on that processor, i.e. originating from a party that holds the private key and is thereby authorised to supply applications for the processor in question (typically the designer or manufacturer of the chip, or an authorised partner of theirs). A similar process could also be used to authenticate data files.
Nonetheless, it may be desirable to be able unlock individual production processors so they can run trial software. This should be done in such a way as to avoid compromising devices that have not been explicitly unlocked.
Conventionally this is often done using a secret back door. However, this approach is flawed since obscurity is not an adequate security measure—the “obscure” secret back door mechanism may become publicly known and if it does then the security of every instance of the processor is compromised.
Otherwise the unlocking feature may not be provided at all, making it impossible to provide trial software to specific devices. In this case, the only way to allow trial software would be to divulge the private production key, which would be expensive due to the security procedures involved, and would also risk comprising the production key and thereby compromising the security of every instance of the processor.
Approaches have been suggested involving secure databases of chip IDs stored when devices are manufactured. However, these databases would be inherently difficult to maintain securely, given the manufacturing environment.
It would be desirable to provide a processor that can be unlocked to run unsigned trial software, but without significantly compromising the security of every instance of the processor.